A process is a running instance of a software program including all variables and sequences of process states. A process may have many software threads which are threads of execution. Threads are a way for a program to split itself into two or more simultaneously (or pseudo-simultaneously) running tasks (i.e., execution paths through address space). A signal is an example of an inter-process communication that occurs between processes. The task of selecting a software thread to handle a signal can be time consuming if the process associated with the thread has a large number of threads.
Several prior solutions have been implemented to attempt to solve the problem of performing excessively long (time consuming) thread searches for finding candidate threads for signal delivery. The first prior solution created a per-process signalable thread list (i.e., list of threads that could handle signals on a per-process basis). This solution searches only threads on that thread list as candidates for signal delivery signal, instead of searching the entire per-process thread list. A problem with this prior solution is that this per-process signalable thread list would not be significantly shorter or less than the entire per-process thread list if most of the threads of the process were signalable. Therefore, this solution could also result in the time consuming thread searches and wasted processor cycles due to the searches. Additionally, this prior solution was designed to only benefit particular processes which had mostly non-signalable threads (i.e., threads that do not handle signals such as system threads) in the per-process thread list.
A second prior solution used a signal bit mask in the process structure to mark signals that were completely blocked by the process. A process would have a signal bit set for a particular signal that no threads in the process could handle (i.e., a particular signal that was masked by all the threads). This saved the sender the cost of searching the thread list for a completely blocked signal. It also avoided having each thread in the process searching other threads (in the process) that could instead handle this particular masked signal. This prior solution was intended to stop the repeated (and often unnecessary) searches for candidate (target) threads for handling the signals which were masked off by every thread in a heavily threaded process. Like the above-mentioned first prior solution, the problem with this second prior solution was that this second solution was tuned to fix a particular customer application. In this case, the application constantly sends signals to processes with a large number of threads which had the signals masked off, and the threads are required to search for other threads that are capable of handling the signal that the running thread itself has masked off. Furthermore, the per-process signal bit mask may involve very frequent resets and still require a full thread list search to maintain up to date values. Therefore, this solution could also result in the time consuming thread searches and wasted processor cycles due to the searches.
Therefore, the current technology is limited in its capabilities and suffers from at least the above constraints and deficiencies.